Rich drag drop user interface

ABSTRACT

In an electronic file system, preview information is provided to the user during a drag operation of a selected object onto a target object. The information indicates what type(s) of action is to be taken should the selected object be dropped onto the target object. The action(s) to be taken may depend upon the type of the selected object and/or the type of the target object. For example, where the selected object is an item and the target object is a persisted auto-list, the action may include adding, removing, or modifying one or more properties of the selected object to conform to one or more criteria defined by the persisted auto-list. Also, numerical feedback may be provided to the user where multiple objects are selected. For example, where seven objects are selected, the textual number “7” may appear next to the cursor.

This application is a continuation of prior U.S. patent application Ser.No. 11/179,804, filed Jul. 13, 2005, which is a continuation-in-part ofU.S. patent application Ser. No. 10/440,035, filed May 16, 2003, whichis a continuation-in-part of U.S. patent application Ser. No.10/403,341, filed Mar. 27, 2003. As such, priority is claimed to each ofU.S. patent application Ser. No. 11/179,804; U.S. patent applicationSer. No. 10/440,035; and U.S. patent application Ser. No. 10/403,341,each of which is incorporated by reference herein as to its entirety.

BACKGROUND

Modem electronic file systems typically store files in a hierarchicaltree structure. Each node of the tree is considered a folder thatcontains one or more files. Typically, in such electronic file systemsthe location of an item is limited by the organization defined the filesystem. For example, in many file systems each file is located in one(and only one) folder. This means that file lifetime and fileorganization are conflated. That is, a file can exist only while it hasa location organized relative to other files or folders. In addition, afile cannot be placed in multiple organizations. This means that if auser wishes to view a file in multiple folders, for example, the usermust make multiple copies of the file. This is both tedious anderror-prone for the user, as well as wasteful of storage space.

In addition, when performing a drag/drop operation, it is not alwaysclear to the user what action is going to be taken upon completion ofthe drag/drop operation. It can be even more confusing when multiplefiles for dragging/dropping have been selected together.

SUMMARY

There is a need for a more advanced electronic file system and userinterface that more allows users to manipulate files and other objectsin a more flexible way using a graphical user interface. With thisflexibility comes an opportunity to provide richer information to theuser as to what is happening while drag/drop operations are beingperformed.

Aspects of the present disclosure relate to various types of file systemobjects that may be implemented, including items, folders, lists,persisted auto-lists, and stacks. While folders, for example, containactual objects, lists and persisted auto-lists contain references, orshortcuts, to objects, as opposed to the objects themselves. A persistedauto-list is automatically populated with references to objects havingproperties that conform to one or more criteria defined by the persistedauto-list.

Further aspects of the present disclosure are directed to providingpreview information to the user during a drag operation of a selectedobject onto a target object in a graphical user interface. The previewinformation indicates what type(s) of action is to be taken if theselected object were to be dropped onto the target object, therebyproviding the user with an opportunity to determine whether theparticular drag/drop operation is desirable, before the drag/dropoperation is completed. The particular action(s) to be taken may dependupon the type of the selected object and/or the type of the targetobject. For example, where the selected object is an item and the targetobject is a persisted auto-list, the action may include adding,removing, or modifying one or more properties of the selected object toconform to one or more criteria defined by the persisted auto-list.

Still further aspects of the present disclosure are directed toproviding numerical feedback to the user when multiple objects areselected. For example, where seven objects are selected, the textualnumber “7” may appear next to the cursor. This may result in a mucheasier-to-understand user interface than in past interfaces where themultiple objects are scattered around the screen as they move. Inconventional interfaces, it is sometimes difficult for a user todetermine how many objects have been selected.

Still further aspects of the present invention are directed toperforming various types of actions in response to different drag/dropcombinations. The particular type of action performed may be determinedby the type of the object being dropped and/or the type of the targetobject onto which the drop is to occur.

These and other aspects of the disclosure herein will be apparent uponconsideration of the following detailed description of illustrativeembodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing summary, as well as the following detailed description ofillustrative embodiments, is better understood when read in conjunctionwith the accompanying drawings, which are included by way of example,and not by way of limitation with regard to the claimed invention.

FIG. 1 is a functional block diagram of an illustrative computingenvironment.

FIG. 2 is a table showing illustrative actions that may be taken inresponse to particular drag/drop operations.

FIGS. 3-10 show illustrative preview feedback instances that may bepresented in response to various drag/drop operations.

FIGS. 11-13 show illustrative screenshots where a drag/drop operationcauses a preview feedback instance to be presented either near thecursor or in another location on the screen.

FIG. 14 shows illustrative preview feedback instances that may bepresented m response to dragging an item over various types of targetobjects.

FIGS. 15-18 show illustrative preview feedback instances that eachinclude explanatory text.

FIGS. 19-23 show an illustrative response to dragging an object over atarget object having child objects below it in a hierarchy.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS Illustrative ComputingEnvironment

FIG. 1 illustrates an example of a suitable computing environment 100 inwhich handwriting recognition functions and/or neural network creation,modification, and/or training may be implemented. Computing environment100 is only one example of a suitable computing environment and is notintended to suggest any limitation as to the scope of use orfunctionality of the invention. Neither should computing environment 100be interpreted as having any dependency or requirement relating toanyone or combination of components illustrated in illustrativecomputing environment 100.

Other general purpose or special purpose computing system environmentsor configurations may be used. Examples of well known computing systems,environments, and/or configurations include, but are not limited to,personal computers (PCs); server computers; hand-held and other portabledevices such as personal digital assistants (PDAs), tablet-style PCs orlaptop PCs; multiprocessor systems; microprocessor-based systems; settop boxes; programmable consumer electronics; network PCs;minicomputers; mainframe computers; distributed computing environmentsthat include any of the above systems or devices; and the like.

The disclosure herein is at times described in the general context ofcomputer-executable instructions, such as program modules, beingexecuted by a computer. Generally, program modules include routines,programs, objects, components, data structures, etc. that performparticular tasks or implement particular abstract data types.Distributed computing environments may further be used where tasks areperformed by remote processing devices that are linked through acommunications network. In a distributed computing environment, programmodules may be located in both local and remote computer storage mediaincluding memory storage devices.

With reference to FIG. 1, illustrative computing environment 100includes a general purpose computing device in the form of a computer100. Components of computer 100 may include, but are not limited to, aprocessing unit 120, a system memory 130, and a system bus 121 thatcouples various system components including system memory 130 toprocessing unit 120. System bus 121 may be any of several types of busstructures including a memory bus or memory controller, a peripheralbus, and a local bus using any of a variety of bus architectures. By wayof example, and not limitation, such architectures include IndustryStandard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus,Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA)local bus, Advanced Graphics Port (AGP) bus, and Peripheral ComponentInterconnect (PCI) bus, also known as Mezzanine bus.

Computer 100 typically includes a variety of computer-readable media.Computer readable media can be any available media that can be accessedby computer 100 such as volatile, nonvolatile, removable, andnon-removable media. By way of example, and not limitation,computer-readable media may include computer storage media andcommunication media. Computer storage media may include volatile,nonvolatile, removable, and non-removable media implemented in anymethod or technology for storage of information such ascomputer-readable instructions, data structures, program modules orother data. Computer storage media includes, but is not limited to,random-access memory (RAM), read-only memory (ROM),electrically-erasable programmable ROM (EEPROM), flash memory or othermemory technology, compact-disc ROM (CD-ROM), digital video disc (DVD)or other optical disk storage, magnetic cassettes, magnetic tape,magnetic disk storage or other magnetic storage devices, or any othermedium that can be used to store the desired information and which canaccessed by computer 100. Communication media typically embodiescomputer-readable instructions, data structures, program modules orother data in a modulated data signal such as a carrier wave or othertransport mechanism and includes any information delivery media. Theterm “modulated data signal” means a signal that has one or more of itscharacteristics set or changed in such a manner as to encode informationin the signal. By way of example, and not limitation, communicationmedia includes wired media such as a wired network or direct-wiredconnection, and wireless media such as acoustic, radio frequency (RF)(e.g., BLUETOOTH, WiFi, UWB), optical (e.g., infrared) and otherwireless media.

System memory 130 includes computer storage media in the form ofvolatile and/or nonvolatile memory such as ROM 131 and RAM 132. A basicinput/output system (BIOS) 133, containing the basic routines that helpto transfer information between elements within computer 100, such asduring start-up, is typically stored in ROM 131. RAM 132 typicallycontains data and/or program modules that are immediately accessible toand/or presently being operated on by processing unit 120. By way ofexample, and not limitation, FIG. 1 illustrates software in the form ofcomputer-executable instructions, including operating system 134,application programs 135, other program modules 136, and program data137.

Computer 100 may also include other computer storage media. By way ofexample only, FIG. 1 illustrates a hard disk drive 141 that reads fromor writes to non-removable, nonvolatile magnetic media, a magnetic diskdrive 151 that reads from or writes to a removable, nonvolatile magneticdisk 152, and an optical disk drive 155 that reads from or writes to aremovable, nonvolatile optical disk 156 such as a CD-ROM, DVD, or otheroptical media. Other computer storage media that can be used in theillustrative operating environment include, but are not limited to,magnetic tape cassettes, flash memory cards, digital video tape, solidstate RAM, solid state ROM, and the like. Hard disk drive 141 istypically connected to system bus 121 through a non-removable memoryinterface such as an interface 140, and magnetic disk drive 151 andoptical disk drive 155 are typically connected to system bus 121 by aremovable memory interface, such as an interface 150.

The drives and their associated computer storage media discussed aboveand illustrated in FIG. 1 provide storage of computer-readableinstructions, data structures, program modules and other data forcomputer 100. In FIG. 1, for example, hard disk drive 141 is illustratedas storing an operating system 144, application programs 145, otherprogram modules 146, and program data 147. Note that these componentscan either be the same as or different from operating system 134,application programs 135, other program modules 136, and program data137, respectively. Operating system 144, application programs 145, otherprogram modules 146, and program data 147 are assigned differentreference numbers in FIG. 1 to illustrate that they may be differentcopies. A user may enter commands and information into computer 100through input devices such as a keyboard 162, a touch pad 165 (such as adigitizer) and stylus 166, and a pointing device 161 (commonly referredto as a mouse, trackball or touch pad). Touch pad 165 may be a separatephysical device or may be integrated with a display device such as amonitor 191. Other input devices (not shown) may include a microphone,joystick, game pad, satellite dish, scanner, or the like. These andother input devices are often coupled to processing unit 120 through auser input interface 160 that is coupled to system bus 121, but may beconnected by other interface and bus structures, such as a parallelport, game port, universal serial bus (USB), or IEEE 1394 serial bus(FIREWIRE). Monitor 191 or other type of display device is also coupledto system bus 121 via an interface, such as a video interface 190. Videointerface 190 may have advanced 2D or 3D graphics capabilities inaddition to its own specialized processor and memory. Computer 100 mayalso include other peripheral output devices such as speakers 197 and aprinter 196, which may be connected through an output peripheralinterface 195.

Computer 100 may operate in a networked environment using logicalconnections to one or more remote computers, such as a remote computer180. Remote computer 180 may be a personal computer, a server, a router,a network PC, a peer device or other common network node, and typicallyincludes many or all of the elements described above relative tocomputer 100, although only a memory storage device 181 has beenillustrated in FIG. 1. The logical connections depicted in FIG. 1include a local area network (LAN) 171 and a wide area network (WAN)173, but may also or alternatively include other networks, such as theInternet. Such networking environments are commonplace in homes,offices, enterprise-wide computer networks, intranets and the Internet.

When used in a LAN networking environment, computer 100 is coupled toLAN 171 through a network interface or adapter 170. When used in a WANnetworking environment, computer 100 may include a modem 172 or anotherdevice for establishing communications over WAN 173, such as theInternet. Modem 172, which may be internal or external, may be connectedto system bus 121 via user input interface 160 or another appropriatemechanism. In a networked environment, program modules depicted relativeto computer 100, or portions thereof, may be stored remotely such as inremote storage device 181. By way of example, and not limitation, FIG. 1illustrates remote application programs 182 as residing on memory device181. It will be appreciated that the network connections shown areillustrative, and other means of establishing a communications linkbetween the computers may be used.

File System Organization

An electronic file system may be implemented by computer 100 to managefiles and other objects stored in the various electronic media to whichcomputer 100 has access. The file system may be part of the otherprogram modules 136 and/or part of operating system 134. The file systemmay be a traditional file system or a more advanced filing system thatmay be database-driven. In many traditional file systems, such as thosebased on a file allocation table (FAT) file system, traditionaldirectory access to files assumes that users wish to maintain theirfiles in a hierarchical directory tree. Files locations and thedirectory structure are dependent on one another; a user cannot move afile to another location without changing the directory structure.

On the other hand, a more advanced file system may be used that usesshortcut references, thus allowing files and other objects to appear inone or more location while actually being in another, differentlocation. Such a file system may define various types of objects thatprovide a much more flexible way of managing files and other objects.

For example, one type of object is a list. For purposes of the presentdisclosure and claims, a list is an object that references a set ofother objects in a particular order. The term “set” of objects as usedin the present disclosure and claims is intended to include both a setof a plurality of objects and a set having only a single object. Theobjects referenced by the list may, for example, be an arbitrary set ofobjects each added to the list manually by the user. However, theobjects referenced by a list are not actually stored in the list as theyare in a conventional folder. Thus, more than one list maysimultaneously reference the same object.

Another type of object that may be supported by the file system is apersisted auto-list. A persisted auto-list is similar to a list exceptthat the set of objects referenced by a persisted auto-list aredetermined by a query. The query may define one or more criteria. Thus,for purposes of the present disclosure and claims, a persisted auto-listis defined as a list containing a set of objects that meet one or morecriteria associated with the persisted auto-list. The content of apersisted auto-list is dynamic; the set of objects listed in a persistedauto-list may change in accordance a change in properties of variousobjects. For example, a persisted auto-list configured to containreferences to all documents created by author John Doe (the querycriteria in this case being type=documents and author=“John Doe”) mayautomatically update when John Doe creates a new file or deletes one ofhis files. The criteria associated with a persisted auto-list mayinclude any criteria, such as object type, author, title, content,creation date, edit date, location in the file system (also referred toherein as “scope”), custom intrinsic properties, etc. Also, as discussedbelow, lists allow for extrinsic properties to be defined for objectsreferenced by those lists and persisted auto-lists.

Each object managed by the file system may include or otherwise beassociated with one or more properties. These properties may be broadlycategorized into two groups: extrinsic properties and intrinsicproperties. The one or more criteria associated with a persistedauto-list form a query on the intrinsic properties of objects.

An extrinsic property is a property of an object that is storedseparately from the object. In the context of a list, for example, theuser may add a “List Notes” column that places comments only within thecontext of the list and not on the objects themselves that arereferenced by the list. This may allow the user to make comments onobjects that the user does not have the right to modify, for instance.Extrinsic properties would not travel with those objects outside of thecontext of that list. Thus, another list that references one or more ofthose same objects would not include the “List Notes” property of any ofthose items, unless of course the user added that property to the itemsin the context of the other list. Extrinsic properties may be manuallyadded by the user or automatically added by the file system, operatingsystem, and/or other program module.

An intrinsic property is a property that is stored with the item. Forexample, the title of a file may be considered to be an intrinsicproperty of the file where the title travels with the file. If the filewere added to a particular folder or list, for instance, the file wouldstill have its title. The content of an object is also an intrinsicproperty of the object. Also, the location of the object within the filesystem is another intrinsic property of the object.

Still another type of object that may be supported by the file system isa conventional folder. A folder is defined for purposes of the presentdisclosure and claims as an object that contains a set of other objects.A related type of object is a stack, which is a virtual container in aview representing the set of items that meet a given requirement. Forinstance, the user may stack a persisted auto-list or query results by“author” and then view all results by who wrote them. A stack would bepresented for each author, where each stack may be of a different heightbased on the number of objects written by each author.

Still another type of object that may be supported by the file system isan item. An item may be, for example, a file, an email, a contact, or anappointment.

Objects referenced by lists and persisted auto-lists, as well as objectscontained in folders and stacks, may be any types of objects in anycombination. For example, a list, persisted auto-list, folder, or stackmay each contain one or more files, emails, lists, persisted auto-lists,folder, stacks, and/or any other types of objects.

The file system may be organized into one or more volumes. A volume isdefined for purposes of the present disclosure and claims as a physicalstorage medium or predetermined portion thereof represented by the filesystem as an individual storage resource.

Dragging/Dropping Objects

The operating system and/or file system may have a graphical userinterface that presents an icon or other visual element that representseach object managed by the file system. The graphical user interface mayfurther allow the user to drag and drop visual elements representingobjects onto other visual elements representing other objects in aconventional manner. The terms “drag/drop” or “drag and drop” of a firstobject over or onto a second object, and variations thereof, will beused herein as shorthand language for the conventional dragging anddropping of a visual element representing the first object onto a visualelement representing the second object. Many systems, such asMicrosoft's WINDOWS line of operating systems, traditionally providedrag/drop functionality. Dragging and dropping can have differentmeanings in different contexts. For example, dragging a file onto afolder typically causes the file to be moved to into the folder. Inother words, the location of the actual file object itself in the filesystem is changed. Also, dragging a document onto a printer objectcauses typically causes the document to be printed on the printerassociated with the printer object. It should be noted that many suchoperating systems and file systems also provide for cut/copy/pastefunctionality. These are considered alternate user operations thatobtain the same result. For example, dragging and dropping a file into alist may alternatively be accomplished by copying the file and pastingthe file into the list.

However, drag/drop meanings need to be established between variouscombinations of objects and for contexts that have not previously beensupported in traditional systems. For example, what does it mean to dropan item into an existing persisted auto-list? Examples of such drag/dropmeanings are discussed herein, with reference to FIG. 2. FIG. 2 showswhich action(s) is/are to be performed in response to a drag/drop inputmade by the user. Each row in FIG. 2 corresponds to a different type ofobject that is to be dropped (the “selected object”), and each columncorresponds to a different type of object (the “target object”) ontowhich the selected object is to be dropped.

Thus, FIG. 2 deals with six different possible types of selectedobjects: a single item, a group of multiple items, a folder, a list, apersisted auto-list, and a stack. FIG. 2 also deals with six differentpossible types of target objects: a folder within the same volume as theselected object, a folder in a different volume from the selectedobject, a list within the same volume as the selected object, a list ina different volume from the selected object, an auto-list defining ascope (i.e., location in the file system) that includes the selectedobject, and an auto-list defining a scope that does not include theselected object.

FIG. 2 will now be discussed on a column-by-column basis. Referring tothe “Folder (same volume) column of FIG. 2, where the target object is afolder in the same volume as the selected object, then the action takenis to move the selected object to be within the target object,regardless of the type of selected object. This makes sense as it ismost likely the user's intention when the selected object and the targetobject are within the same volume.

Similarly, referring to the “Folder (different volume)” column, wherethe target object is a folder in a different volume from the selectedobject, then the action taken is to copy the selected object and placethe copy within the target object, regardless of the type of selectedobject. Again, it is most likely the user's intention in this case thata copy of the selected object be placed in the target object, and notthe original selected object itself, where the target object is in adifferent volume. There is an exception where the selected object is astack, however. In this case, dragging/dropping a selected stack to atarget folder results in a persisted autolist being created thatrepresents the selected stack in the target folder.

Referring to the “List (same volume)” and “List (different volume)”columns of FIG. 2, where the target object is a list, a drag/dropoperation would cause a reference, or shortcut, to the selected objectis placed in the list. This is true regardless of whether the targetlist is within the same volume as the selected object. There is anexception where the selected object is a stack, however. In this case,dragging a selected stack to a target list from a persisted auto-listresults in a shortcut to the definition of the persisted autolist beingcreated, which is embedded within the target list (not persisted as aseparate file). Again, these are most likely the user's intentions whenthe user performs such drag/drop operation.

Referring to the “Auto-List (same scope)” column of FIG. 2, dragging anyselected item(s) onto a persisted auto-list defining a scope thatincludes the selected object causes one or more properties of theselected object to be modified, removed, or added so that the selectedobject falls within the criterion or criteria defined by the targetpersisted auto-list. For example, assume that the target persistedauto-list defines criteria that objects referenced by the persistedauto-list must be (type=document) and (author=“John Doe”), with a scopeof folder c:\work\clientxyz. In this case, the persisted auto-list wouldautomatically list all objects within its scope that meet thosecriteria. Assume, for example, that a document is within the definedscope but either has no author assigned or has a different authorproperty assigned to it. The operation of dragging and dropping thedocument onto the target persisted auto-list would cause properties ofthe document to be set, if possible, so as to meet the criteria requiredby the persisted auto-list. In this example, the author property of thedocument would be changed to “John Doe” so that the document mayproperly be listed by the persisted auto-list.

It is possible in certain situations that computer 100 determines thatit is not possible to change the properties so as to meet all thecriteria. For instance, if the object being dropped onto that sametarget persisted auto-list were not a document, then it would not makesense to change the type property of that object to be a document (sinceit is not in fact a document). In that case, the drag/drop operation maybe disallowed.

Where the selected object to be dragged/dropped onto the targetpersisted auto-list in the same scope as the selected object is afolder, then the properties that are changed to meet the persistedauto-list criteria causes the items in the folder (but not the folderitself) to be referenced by the persisted auto-list Likewise, theproperties of the items in the selected folder are changed wherepossible to meet the criteria of the target persisted auto-list.

Where the selected object is a persisted auto-list, thendragging/dropping it onto another target persisted auto-list will setproperties on the persisted auto-list results. In other words,properties of all of the items that conformed to the selected auto-listare changed, removed, or added such that they also conform to the targetauto-list.

Where the selected object is a stack, then dragging/dropping it onto atarget persisted auto-list will set the properties, where possible, ofthe contents of the stack to meet the criteria of the target persistedauto-list.

Referring to the “Auto-List (different scope)” column of FIG. 2, thiscolumn refers to the same situations as the previous column, except thatnow the selected object is outside the scope of the target persistedauto-list. In these cases, the selected object (or the objectsreferenced by the selected object, such as the objects listed in aselected list) is first copied, and the copy is placed within the scopeof the target persisted auto-list. Then, the same actions referred to inthe “Auto-List (same scope)” column are performed, except that theactions are performed on the copy instead of the original selectedobject.

Drag/Drop Modifiers

The actions resulting from the various drag/drop operations discussed inthe examples above with regard to FIG. 2 are default actions. Thedefault actions attempt to predict what the user's intentions are inperforming each drag/drop operation. However, the user may manuallyoverride the actions to be taken by providing additional input alongwith a drag/drop operation. For example, the user may press a key onkeyboard 162 while the drag/drop operation is being performed. Forexample, pressing the Shift key may cause any copy actions to be moveactions, and pressing the Ctrl key may cause any move actions to insteadbe copy actions.

As further examples, when dragging to a list, pressing the Shift keywhile dragging may force the selected object to be moved to the targetlist's thicket folder, which is the location where the target listplaces objects when it collects objects. Or, when dragging to a listwhile pressing the Ctrl key, this may force the selected object to becopied to the list's thicket folder. When dragging to a persistedauto-list, then pressing the Shift key while dragging may force theselected object to be moved to the target persisted auto-list's defaultfolder, which is the location where objects are placed when they arecopied into the target auto-list's scope. Or, when dragging to apersisted auto-list while pressing the Ctrl key, this may force theselected object to be copied to the target persisted auto-list's defaultfolder.

Drag/Drop Preview

Because there are now a wide variety of possible actions that may betaken in response to a drag/drop operation, it may be easy for the userto become confused as to what a particular drag/drop operation may mean.This may be true even though the system may be configured to take themost likely intended actions. Accordingly, it may be desirable topresent feedback to the user a preview of some or all of the actionsthat are about to happen as a result of a given drag/drop operation,and/or a current status of the drag/drop operation. Based on thisfeedback, the user may then decide whether to complete, abort, or modifythe drag/drop operation as desired.

This preview feedback may be presented in any form desired. Forinstance, the feedback may be in the form of iconic, graphical, textual,and/or any other type of feedback, and may be presented in any fixed ornon-fixed portion of the display. The feedback may be visual and/oraudible. Moreover, the feedback may move with the cursor and/or may bepresented proximate to the cursor.

Examples of such preview feedback are shown in FIGS. 3-10. The shownfeedback instances are merely illustrative. FIG. 3 shows an example ofvisual feedback that may occur during a pending drag/drop operation whenthe operation cannot be completed. This may occur, for example,responsive to the user having dragged an item over a persisted auto-listwhere the properties of the item cannot be modified to meet the criteriaof the persisted auto-list.

FIG. 4 shows an example of visual feedback that may occur during apending drag/drop operation, indicating that the selected object will becopied in response to completion of the drag/drop operation. This mayoccur, for example, responsive to the user having dragged an item to afolder in a different volume.

FIG. 5 shows an example of visual feedback that may occur during apending drag/drop operation, indicating that multiple items have beenselected. In this example, fourteen items have been selected. The numbermay dynamically change to indicate the actual number of items selectedas each new item is added to the selection. In many conventionalgraphical user interface file systems, the selection of multiple filesis indicated by the various icons of the files moving from theiroriginal displayed positions to new relative positions in accordancewith the cursor. It can be difficult in that situation for the user tounderstand what is going on and how many files have been selected oncetheir icons begin moving. In FIG. 5, however, the status of how manymultiple selected items is easily viewed by the user. The icon to theleft of the number in FIG. 5 may be a thumbnail of one of the selecteditems, such as the first item selected or the most recent item selected.Other information may also be provided such as the number of bytesselected.

FIG. 6 shows an example of visual feedback that may occur during apending drag/drop operation, indicating that the selected object will beadded to a target list or target persisted auto-list in response tocompletion of the drag/drop operation.

FIG. 7 shows an example of visual feedback that may occur during apending drag/drop operation, indicating that a property of the selectedobject is to be added, removed, or modified, in response to completionof the drag/drop operation.

FIG. 8 shows an example of visual feedback that may occur during apending drag/drop operation, indicating that a persisted auto-list is tobe created in response to completion of the drag/drop operation. Apersisted auto-list may be created in response to a drag/drop operationwhen, for example, a user drags a particular stack from an existing setof query results and drops the stack somewhere. In this case, a newpersisted auto-list may be automatically created, in response to thedrag/drop operation, that persists out the definition of that query.

FIG. 9 shows an example of visual feedback that may occur during apending drag/drop operation, indicating that the selected object is tobe moved in response to completion of the drag/drop operation.

Where more than once action is to be taken, the various feedbackinstances, such as the icons in FIGS. 4-9, may be combined. Forinstance, FIG. 10 shows an example of visual feedback that may occurduring a pending drag/drop operation, indicating that certain multipleactions are to be taken in response to completion of the drag/dropoperation. In this example, responsive to completion of the pendingdrag/drop operation, three actions will be taken: the selected objectwill be copied, at least one of its properties will be added, removed,or modified, and a new persisted auto-list will be created. Although inthis example the various icons are shown horizontally arranged, they maybe arranged vertically or in any other manner.

With the exception of the feedback shown in FIG. 5, each of thesefeedback instances may be presented to the user responsive to theselected object being moved proximate to (e.g., within a thresholddistance of; or overlaying) the target. For instance, referring to FIG.11, a screen 1100 is shown in which a user is about to drag a selectedobject 1101 over to a target object 1102 using cursor 1103. Referring toFIG. 12, selected object 1101 has now been dragged and is now proximateto (and indeed, in this case, overlaying) target object 1102. Inresponse, feedback 1201 is presented proximate to cursor 1103.Alternatively, or additionally, with reference to FIG. 13, feedback 1301may be presented in a location on screen 1100 unrelated to the positionof cursor 1103, such as in a pre-existing status bar or in a pop-upwindow.

As already mentioned, the particular feedback provided to the userdepends upon which action(s) are to be taken upon completion of thedrag/drop operation. An example of feedback that may be provided isshown in FIG. 14, with reference to the “Item” row of the table in FIG.2. Where an item 1401 is dragged over a folder 1402 in the same volume,feedback as in FIG. 9 is provided, indicating that item 1401 would bemoved into folder 1402 upon dropping item 1401 there. Where item 1401 isdragged over a folder 1403 in a different volume, feedback as in FIG. 4is provided, indicating that item 1401 would be copied into folder 1403upon dropping item 1401 there. Where item 1401 is dragged over a list1404 in the same volume, feedback as in FIG. 6 is provided, indicatingthat a reference to item 1401 would be added to list 1404 upon droppingitem 1401 there. The same is indicated where item 1401 is dragged over alist 1405 in a different volume. Where item 1401 is dragged over apersisted auto-list 1405, and where item 1401 is within the scope ofpersisted auto-list 1405, feedback as in FIG. 7 is provided. Suchfeedback indicates that one or more properties of item 1401 will bemodified such that item 1401 will be listed in persisted auto-list 1405,upon dropping item 1401 there. Where item 1401 is dragged over apersisted auto-list 1406, and where item 1401 is outside the scope ofpersisted auto-list 1405, feedback as in FIGS. 4 and 7 is provided. Suchfeedback indicates that item 1401 will be copied to a location withinthe scope, and that one or more properties of the copy of item 1401 willbe modified such that the copy of item 1401 will be listed in persistedauto-list 1405, upon dropping item 1401 there.

Referring to FIGS. 15-18, the preview feedback may additionally oralternatively include a textual explanation that more fully explainsdetails of each action to be taken. For example, the feedback instancein FIG. 15 indicates to the user that properties of the selected itemwill be changed, and in particular the labels “Projects” and “Work” willbe added as intrinsic properties to the item. The feedback instance inFIG. 16 indicates to the user that the selected item will be copied andits properties will be modified, and in particular that the selecteditem will be copied to the location Desktop and the labels “Urgent” and“Personal” will be added as intrinsic properties to the selected item.

The feedback instance in FIG. 17 also provides detailed information tothe user. In this case, the selected item will be copied to the locationClient Work Folder, and various indicated labels will be added asproperties to the item. It should be noted that, where the descriptivetext becomes too long, as in FIG. 17, the text may fade away as shown.The feedback instance in FIG. 18 indicates not only that the drag/dropoperation will not work, but also why it will not work. In this example,the operation will not work because a non-document is being dragged overa persisted auto-list defining a criteria that allows only documents tobe referenced.

Dragging/Dropping into Child Objects in a Hierarchy

Thus far it has been assumed that the target object has been displayedon the screen during dragging. However, all of the discussion herein mayalso apply to dragging to target objects that are children of suchobjects and that are not displayed on the screen at the beginning of adrag. For example, a main object, such as a folder, list, or persistedauto-list, may contain child objects. The user may desire to drop aselected object into one of the child objects even if only the mainobject is presently being displayed. This may be done as illustrativelydescribed with reference to FIGS. 19-23.

In FIG. 19, the user may select an object 1901 for dragging. Assume thatthe user decides to drop object 1901 onto a child object of folder 1902.Thus, referring to FIG. 20, the user drags object 1901 over folder 1902.In response, computer 100 displays a window 2001 listing the childobjects contained within folder 1902. Referring to FIG. 21, the user maythen drag object 1901 down over window 2001 to select a particular childobject listed therein as desired. As object 1901 is dragged over eachchild object, appropriate preview feedback may be provided to the user.For example, as object 1901 is dragged over the first child objectlisted (“Persisted AutoList A”), a preview feedback 2101 indicatingthat, should object 1901 be dropped there, the properties of object 1901would be modified to add “Work” to its Keyword property and “Client XYZ”to its Client property. This is likely because Persisted AutoList Adefines criteria that require these properties of any object that isreferenced by it.

As the user continues to drag object 1901 down over window 2001, object1901 may eventually be positioned over List E, as shown in FIG. 22. Inthis case, preview feedback 2201 is presented that indicates that object1901 would be referenced by List E upon dropping object 1901 over it.The user may choose to do so. The user may alternatively choose not todrop object 1901 on any of the child objects shown in window 2001, andinstead either abort the drag/drop or drag onto a completely differentfolder. In this case, user may drag object 1901 away from folder 1902and window 2001, as shown in FIG. 23. As shown, in response to draggingobject 1901 away from folder 1902 and/or window 2001, window 2001automatically disappears. This may provide for a convenient way for theuser to drop objects onto other objects located deep in a hierarchywithout having to manually open and close container objects such asfolder, lists, and persisted auto-lists.

CONCLUSION

Thus, an improved way of managing objects in an electronic file systemhas been described. In accordance with various aspects of the presentdisclosure, the drag/drop operation has become a powerful tool fordealing with the concepts of lists, persisted auto-lists, and stacks,for example. In addition, to deal with this increasing power and thecomplexity that goes with it, the user is now able to preview which of anumber of different possible actions will be taken in response to acompleted drag/drop operation.

1. A computer-readable storage medium storing computer-executableinstructions to perform operations comprising: responsive to detecting afirst request to associate a first object with a first folder in agraphical user interface, presenting to a user feedback that the firstobject will be moved into the first folder as a result of the firstrequest to associate the first object with the first folder; moving thefirst object into the first folder; responsive to detecting a secondrequest to associate a plurality of objects with a second folder in agraphical user interface, presenting to the user feedback that theplurality of objects will be moved into the second folder as a result ofthe second request to associate the plurality of objects with the secondfolder and presenting the user feedback indicating a number of theplurality of objects to be moved; and moving the plurality of objectsinto the second folder.
 2. The computer-readable storage medium of claim1, wherein the first request is a drag/drop operation of the firstobject onto the first folder.
 3. The computer-readable storage medium ofclaim 1, wherein the feedback associated with the first request includesa move icon in the graphical user interface associated with the firstobject.
 4. The computer-readable storage medium of claim 3, wherein thefeedback to the first request includes a textual explanation that thefirst object will be moved to the first folder.
 5. The computer-readablestorage medium of claim 4, wherein the textual explanation includes aname of the first folder.
 6. The computer-readable storage medium ofclaim 1 storing computer-executable instructions to further performoperations comprising: responsive to detecting a third request toassociate a third object with a third folder in the graphical userinterface, presenting to the user feedback that the third object will bemoved into the third folder as a result of the third request toassociate the third object with the third folder and displaying a windowlisting a child folder within the third folder; responsive to detectinga fourth request to associate the third object with the child folder,presenting to the user feedback that the third object will be moved intothe child folder as a result of the request to associate the thirdobject with the child folder; and moving the third object into the childfolder.
 7. A method implemented using a processor and acomputer-readable storage medium, the method comprising: responsive todetecting a first request to associate a first object with a firstfolder in a graphical user interface, presenting to a user feedback thatthe first object will be moved into the first folder as a result of thefirst request to associate the first object with the first folder;moving by the processor the first object into the first folder;responsive to detecting a second request to associate a plurality ofobjects with a second folder in a graphical user interface, presentingto the user feedback that the plurality of objects will be moved intothe second folder as a result of the second request to associate theplurality of objects with the second folder and presenting the userfeedback indicating a number of the plurality of objects to be moved;and moving by the processor the plurality of objects into the secondfolder.
 8. The method of claim 7, wherein the first request is adrag/drop operation of the first object onto the first folder.
 9. Themethod of claim 7, wherein the feedback associated with the firstrequest includes a move icon in the graphical user interface associatedwith the first object.
 10. The method of claim 9, wherein the feedbackto the first request includes a textual explanation that the firstobject will be moved to the first folder.
 11. The method of claim 10,wherein the textual explanation includes a name of the first folder. 12.The method of claim 7, further comprising: responsive to detecting athird request to associate a third object with a third folder in thegraphical user interface, presenting to the user feedback that the thirdobject will be moved into the third folder as a result of the thirdrequest to associate the third object with the third folder anddisplaying a window listing a child folder within the third folder;responsive to detecting a fourth request to associate the third objectwith the child folder, presenting to the user feedback that the thirdobject will be moved into the child folder as a result of the request toassociate the third object with the child folder; and moving the thirdobject into the child folder.
 13. A computing device including aprocessor and computer-storage medium storing computer-useableinstructions that, when used by the computing device, cause thecomputing device to perform a method for managing image and non-imagefiles and folders, the method comprising: responsive to detecting afirst request to associate a first object with a first folder in agraphical user interface, presenting to a user feedback that the firstobject will be moved into the first folder as a result of the firstrequest to associate the first object with the first folder; moving bythe processor the first object into the first folder; responsive todetecting a second request to associate a plurality of objects with asecond folder in a graphical user interface, presenting to the userfeedback that the plurality of objects will be moved into the secondfolder as a result of the second request to associate the plurality ofobjects with the second folder and presenting the user feedbackindicating a number of the plurality of objects to be moved; and movingby the processor the plurality of objects into the second folder. 14.The computing device of claim 13, wherein the first request is adrag/drop operation of the first object onto the first folder.
 15. Thecomputing device of claim 13, wherein the feedback associated with thefirst request includes a move icon in the graphical user interfaceassociated with the first object.
 16. The computing device of claim 15,wherein the feedback to the first request includes a textual explanationthat the first object will be moved to the first folder.
 17. Thecomputing device of claim 16, wherein the textual explanation includes aname of the first folder.
 18. The computing device of claim 13, furthercomprising: responsive to detecting a third request to associate a thirdobject with a third folder in the graphical user interface, presentingto the user feedback that the third object will be moved into the thirdfolder as a result of the third request to associate the third objectwith the third folder and displaying a window listing a child folderwithin the third folder; responsive to detecting a fourth request toassociate the third object with the child folder, presenting to the userfeedback that the third object will be moved into the child folder as aresult of the request to associate the third object with the childfolder; and moving the third object into the child folder.